How to get a good price quote from a development company

Startup owners are most likely to get stumped for the first time when they take their digital product to a software development company. Chances are, all tech entrepreneurs could relate to the moment when they took their remarkable idea, product research, user flows and even some wireframes to a development company, only to get thrown back by the quote.

As someone sitting on the other side of the desk, we can probably talk about why startups get crazy price quotes from development companies, and how to get a good one!

For the sake of credibility, Thorgate has been in the software development industry for over 11 years and we’ve worked with digital product budgets on all scales. A good price quote often comes down to a few key points.

How to start

So, right off the bat, you’d want to know how to kick off the conversation with the development team(s) you want to outsource to. Here’s a few things you’d want to know before that conversation even begins:

To build or to buy? If there’s already an off-the-shelf alternative available, then you might want to consider buying that for a low initial investment, and rapid deployment. You need to have the right reasons to choose to build a product that already has similar alternatives in the market. We’ve covered this in more detail here: “An honest review: should I build or buy?”
Why are you outsourcing your development? So you know for sure that your product needs to be built. If you have a good product idea, and a small team in place, enough research done then you’d probably find a development company happy to work with you. However, you need to clearly know why you are outsourcing your product’s software development to be able to find a company that is a right fit. Some of the reasons could be that you’re looking for a multifunctional team and diverse experience, or maybe you need a dependable service from a team that has already built similar products. If you know ‘why you want to outsource’, you’ll be able to find the right team for you much more easily.
You would need a team that has the right tech stack, industry experience and team size as would be needed for your product.
Are you building a Stand Alone system or does it need to be integrated with other systems? Well, you’ve established why you’re building your product and what kind of team you’d like to work with. However, you’re not quite ready to start talking to potential partners until you’ve determined the details of your product that any good development team would want to know during the first call.

While you could create a stand alone system, which would be both expensive and time-consuming, most successful software products exchange data with other software products. Integration in most cases is inevitable and absolutely necessary.

To deliver and maintain connectivity with other products (and do it at scale), you need to start developing a capability early. You can already brainstorm with your team and interview potential customers to create user stories which would help you assess and categorize low-priority and high-priority integrations, information that is critical to a product development team and would save you some bucks.
If the software is an addition, then which kind of additional features should it provide? You might be building on top of existing software, if that is the case then it is very important that you know what additional features should your software provide and why?

Many product teams struggle with understanding what value to assign a potential new feature. A really common way additional features get built, especially early in the product’s life, is to simply react to a customer request. Inevitably the additional features are created with too many things that are specific to that first customer. It creates an ongoing problem where you've invested time and money into some additions, committed to maintaining them, and no one after that first customer ends up using it.

This scenario and ones like it are quite common and are generally avoidable. If your team has a pre-existing understanding of how you prioritize various features and again, you know ‘why’ and what additional features you’d like to build, it would save you both time and money.
Are you building a product / system from scratch? This point probably reconnects the discussion back to the first question of whether you want to build or buy. If you are building your own product, you would still need to determine if you would build this from scratch or you can use existing systems. This alone can heavily influence your budget and the price quote you’d get from a development company.

Getting a good quote

While this is common knowledge in the tech industry, it might make sense to reiterate that you would start building your product with an MVP, so the quote would first consist of the cost for the said minimum viable product. At Thorgate, we like to use the Pareto principle when describing MVP; it is a product consisting of 20% of the features which give 80% of the required feedback or user satisfaction. There’s one main reason everyone should start with an MVP: it’s all about testing the idea while keeping the expenses as low as possible.

We’ve covered MVP development in detail in our e-book here

Now that the importance of starting with an MVP is out of the way, here’s a few things that can help you get a good price quote from a software company:

Clarity in your product description: The more vague the description of the product or your system is, the more important it becomes for the development team to involve an experienced (read: expensive) product lead to be able to talk and think together with the customer i.e. you. An Illustrative example of this would be:

You would like to build a 2-floor building. In order to get this started you would need to plan the design and have the approvals from the designated city councils for building permits.
If the workers who are hired to build the house have the experience of only brick laying, then there is a high likelihood that this house won’t be built the same way as originally planned.

Point being, if your team is unable to put together a clear, well-defined product description supported with user stories and product flow, then the development team needs someone who can translate your ideas into a technical brief. This is obviously a cost you could avoid by either having the right product lead within your own team or putting together a clear product description.

In addition, you might want to have clarity about your preferred programming language as well. For example, if you have decided that you are looking for a partner for development which is specialized in Java or Python then it makes sense to specify this along with your initial product description.
Why should your product exist: So we’ve briefly touched upon this topic, but it must be understood that unless you very clearly understand and can explain ‘why your product must be built’, chances are you won’t be able to get a good quote. The easiest way for a developer to build your product the way your customer would want is if they can understand why the customer or the market in general needs this product. Be careful when explaining this to the development team because again, this isn’t what we’re building, or how we’re building it, in fact this is the reason why the product MUST exist in the market.

What is a good price quote?

If you’ve checked all the boxes on how to get a good price quote, then it would make sense to also have realistic expectations. Companies are always advised to keep a ~30% of a buffer in the budget (or have that extra 30% available) when building a new software in case additional good ideas pop-up that could exceed the original budget. This is highly likely as your development team helps you research user behavior and general product success during the MVP stage.

It is also necessary to always be transparent about the budget. This applies to both the customer and the development team. As long as you have realistic expectations according to the market prices, you are transparent about your own budget, you keep that 30% buffer, and have clearly defined all your ‘why’s’ (why outsource, why build the product, why choose a certain programming language etc.), you’re very likely to get a good and reasonable price quote from a reputable development company of your choice.